iT邦幫忙

2022 iThome 鐵人賽

DAY 25
1
DevOps

重新認識 devops系列 第 25

Day24:如何評量 DevOps 的進展與成效?(一)

  • 分享至 

  • xImage
  •  

今天來聊一個有點難度的主題——「如何評量 DevOps 的進展與成效?」

嗯,好難喔,我們今天就聊到這裡嘍,明天見~(揍飛)

通常在談論這種主題時,在早一點的年代,我們可能會聽過過一個詞——能力成熟度模型(CMM, Capability Maturity Model)

簡單來說,它通常會是一個表格,將團隊的某項或多項「能力」分成數個層級(多半是 5 個),然後依據團隊可以做到多少事情、做的速度、品質⋯⋯等多項條件做出評比,評定團隊的能力落在哪個等級。

舉例來說,跟 DevOps 很有關係的持續交付成熟度模型(The Continuous Delivery Maturity Model),就分成五個等級 basebeginnerintermediateadvancedexpert,評定 Culture & OrganizationDesign & ArchitectureBuild & DeployTest & VerificationInformation & Reporting 五個面向。
https://ithelp.ithome.com.tw/upload/images/20221010/20120986bQpxSiCEOt.png
(圖片來自 infoq.com 的文章。)

除了持續交付之外,還有哪些成熟度模型呢?只要去 Google 搜尋 Maturity Model,就能找到許許多多不同主題的「成熟度模型」例如:Test Maturity Model、Automation Maturity Model、Release Management Maturity Model⋯⋯,其中有一些確實是經過一些專家或大神們訂定的,當然也有一些是不知哪來的公司或顧問自己訂定的。

總之,成熟度模型是一個在概念上歷史悠久,過往會被拿來評定團隊各種能力的一項工具。

不過這種歷史悠久的工具,並非所有人都接受它,也是有一些不同的聲音出現,例如:

  • 成熟度模型無法因應現在 IT 圈的高度不確定性、變動性與複雜性。
  • 成熟度模型無法反映出個別團隊的差異與獨特性,它是一種僵化、固定的標準。
  • 就算達到了成熟度模型的最高等級,依然對於企業能否成功沒有直接幫助。
  • 成熟度模型只是一種變相的「認證」,不過是從個人換到了團隊層級而已。
  • 成熟度模型會導致團隊只重視那些可以被評比的項目,忽略了還有其他同樣重要的項目需要被精進與改善。
  • 成熟度模型會阻礙團隊的長遠發展,難道能力只能有 5 個等級嗎?

那目前市面上有沒有 DevOps 的成熟度模型呢?

哼哼,怎麼可能會沒有呢?就像市面上有著 DevOps 職缺、DevOps 認證,當然也會有 DevOps 成熟度模型。就像上面說的,成熟度模型就像認證一樣,這東西背後可是有商機與市場的。

https://ithelp.ithome.com.tw/upload/images/20221010/20120986dBLNLjwngH.png
(老樣子,只要 Google devops maturity model,就可以找到一堆。)

好了,最後讓我們聊一下對於成熟度模型的看法。

基本上就跟 Day21 的內容「你真的需要一張 DevOps 認證?」雷同,請先蒙心自問「你真的需要找一間顧問機構,幫你評定團隊的 DevOps 能力成熟度?」

筆者覺得成熟度模型跟認證很像,它們都能提供一套已經整理齊全的知識體系,幫助我們認識事物的整體輪廓,並提供一個學習與比較的基準。

但這個「基準」就是我們必須謹慎面對的東西,這就好比 KPI 的萬年老梗,「你訂定了錯誤的 KPI,就會得到錯誤的結果。」

重要的不是「成熟度模型」,而是你團隊目前具備的能力,以及團隊打算如何持續改善與成長。「成熟度模型」可以是一項可供我們參考與學習的資源,就是別忘了那句老話「役物而不役於物」啊!

連續假期第三天,今天一樣不多聊嘍~
DevOps 輕鬆聊,我們上班日再見~


上一篇
Day23:DevOps 工程師為何搞不定 DevOps Pipeline?(二)
下一篇
Day25:如何評量 DevOps 的進展與成效?(二)
系列文
重新認識 devops31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言